itest: boot piri on Postgres so the stack comes up; accept any 2xx CORS preflight - #47

Fixes #45. The itest suite is green again — see the note below, because the root cause is not the one #45 diagnosed.

The failure was stack boot, not the CORS test

Every top-level itest failed, and none of them reached an assertion:

Error: initializing piri node: ... ProvideHarmonyDB ...
curio PDP pipeline requires Postgres (set database type to postgres)

Since piri:main absorbed Curio (~2026-07-24) its PDP pipeline refuses sqlite, and forgeStack booted sqlite piri via the zero-value PiriNodeConfig{}. This is pre-existing on main: main's own last itest run (c57186b4, the #42 merge this branch is based on) fails identically — same four suites, 24 occurrences of that error.

All four suites route through that one constructor, so the fix is one line: stack.WithPiriNodes(stack.PiriNodeConfig{Postgres: true}). The pinned smelt already supports it (PiriNodeConfig.Postgres → manifest.DBPostgres), so no dependency bump is involved.

Correction to the #45 diagnosis: the versitygw pin is fine

#45 concluded that the pinned versitygw v0.0.0-20260716095011 predates the CORS work and that the fix required bumping to a fork build with preflight support. That isn't the case — that exact module version already ships the whole stack:

• OPTIONS /:bucket and /:bucket/* routes (s3api/router.go:1547-1561)
• the CORSOptions controller (s3api/controllers/options.go)
• ApplyBucketCORS on every bucket/object route, and ApplyBucketCORSPreflightFallback

Reproducing the itest's exact requests against an in-process server (real versitygw s3api + ingot's config→CORS-document path) shows every header assertion already passing on the current pin: Allow-Origin echoed on the https://*.dev.example wildcard match, Allow-Methods including PUT, Max-Age 600, a bare 403 for a disallowed origin, and Expose-Headers including ETag on a presigned cross-origin GET. No versitygw bump is needed.

The one genuine test defect was the status: versitygw's ProcessController renders every successful controller response as 200 unless MetaOptions.Status is set, and CORSOptions doesn't set it. 204 is only what the no-CORS-config fallback returns — a path ingot never takes, since it reports a CORS configuration for every bucket.

So the assertion now accepts any 2xx, the fetch spec's "ok status" range. Nothing is lost in strictness: the Max-Age == "600" check is what actually pins the real CORS path, because the fallback sets no Max-Age and mirrors the requested method instead of the rule's method list.

Overlap with #44

#44 independently arrived at both of these same changes (piri-on-Postgres, and the 2xx relaxation) as incidental fixes alongside its catalog-retention work. The overlap resolves trivially whichever lands first. #44's note that TestForgeReadAfterEviction would still fail on an upstream piri did:plc proof-verification problem did not reproduce here — it passed in 127.66s.

Verification

itest job green on 574a0a5 (run 30366470280), all four suites passing and TestForgeScenarios/CORS genuinely running rather than skipped:

--- PASS: TestForgeReadAfterEviction (127.66s)
--- PASS: TestForgeNativeProvision (48.71s)
--- PASS: TestForgeScenarios (50.76s)
    --- PASS: TestForgeScenarios/CORS (0.08s)
--- PASS: TestForgeVersity (92.62s)

Zero failures; the remaining skips are the pre-existing curated XFail rows and the documented position-dependent cases. Unit suite green on all three platforms, gofmt clean, go vet -tags itest ./itest clean.